Return verified team reports to the manager conversation - #4945
Conversation
b6ebcfa to
7d1e928
Compare
huangruiteng
changed the title
7d1e928 to
8f2f19b
Compare
8f2f19b to
d187367
Compare
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
动机
manager 确认 team.plan 后，原分配结果应在关闭抽屉、重载之后留在原对话；后来被采用的下游报告也应能回到这张卡片。当前 head 完成了卡片留存和正常合成场景，但混合 Goal 会话下会丢失一个本已可核验的报告。
改动思路
应用回执里的 Todo ID 用于关联计划与团队操作；新 manager 组件读取 Goal Chat 会话、源操作、当前 adoption 和下游操作的产物版本后展示报告。真正的 Todo 写入仍只在 ChatActionService.apply。这里的问题不是版本校验本身，而是“扫描过的所有 Goal 会话都必须能读 team operations”被当作全局完整性条件。
具体改动
新增 manager 结果组件、时间线与重载恢复接线、刷新时撤下旧报告的状态、打包浏览器场景及前端资源。
关键代码讲解
manager-team-result.tsx:10-16：readAdoptedResult无差别列出这个 Goal 的全部聊天会话，并把总会话数超过 8 视为证据不完整。manager-team-result.tsx:21-73：对每个会话读 operations；任一个不相关会话读取失败也设置incomplete，最后覆盖已经找到的有效 adopted 结果。manager-team-result.tsx:79-115：当前 head 在重新核验期间立即撤下旧报告，这部分逻辑与新增浏览器断言一致；原计划卡片由 manager 时间线重新挂载。
对主干的风险
P1 阻塞：不相关普通 Goal 会话会遮蔽有效团队报告。 真实 read_team 对未配置 coordinator identity 的会话返回 400；会话列表本身并不只包含团队会话。保持一份已验收源操作、当前采用关系和匹配的下游报告不变，只往同一 Goal 加一个普通聊天会话、让其 team operations 返回相同的 400：当前 head 的打包 team-plan 场景等待报告表格 30 秒后超时，界面进入“无法核验”。原始九个场景全通过，恰恰因为 fixture 对任意会话都能返回 team API。超过 8 个不相关会话同样会触发 incomplete。
最小修复是按回执 Todo ID 找权威的相关团队会话/公共安全 Goal 结果投影，并独立证明查询完整性；不要简单吞掉所有 400。请增加“有效采用结果 + 无团队配置的普通会话”和“有效结果 + 超过 8 个不相关会话”的打包负例，并重跑 npm run build --prefix apps/presentation/dashboard 与 npm run smoke:personal-workspace-packaged --prefix apps/presentation/dashboard。
我的整体评价
请求修改，当前 head d187367 暂不可合并。 正常路径、关闭/重载、刷新撤下旧报告与九个打包场景通过；但原任务要求把可核验结果可靠地返回 manager，混合会话反例推翻了这一点。无新增持久格式或权威；保留现有 typed API 即可，先修正结果发现/完整性边界再复审。真实多 Agent 验收仍在本 PR 宣称范围之外。
English verdict: REQUEST_CHANGES — an unrelated ordinary Goal session (or the eight-session cap) makes a valid adopted report disappear from the manager conversation; scope discovery and add mixed-session regressions before merge.
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
Request changes conclusion (author-owned PR; GitHub blocks formal self-review)
Exact head: d1873678f97df4eee4a133f13cdfdc79ddc38f3b
动机
manager 确认 team.plan 后，原分配结果应在关闭抽屉、重载之后留在原对话；后来被采用的下游报告也应能回到这张卡片。当前 head 完成了卡片留存和正常合成场景，但混合 Goal 会话下会丢失一个本已可核验的报告。
改动思路
应用回执里的 Todo ID 用于关联计划与团队操作；新 manager 组件读取 Goal Chat 会话、源操作、当前 adoption 和下游操作的产物版本后展示报告。真正的 Todo 写入仍只在 ChatActionService.apply。这里的问题不是版本校验本身，而是“扫描过的所有 Goal 会话都必须能读 team operations”被当作全局完整性条件。
具体改动
新增 manager 结果组件、时间线与重载恢复接线、刷新时撤下旧报告的状态、打包浏览器场景及前端资源。
关键代码讲解
manager-team-result.tsx:10-16：readAdoptedResult无差别列出这个 Goal 的全部聊天会话，并把总会话数超过 8 视为证据不完整。manager-team-result.tsx:21-73：对每个会话读 operations；任一个不相关会话读取失败也设置incomplete，最后覆盖已经找到的有效 adopted 结果。manager-team-result.tsx:79-115：当前 head 在重新核验期间立即撤下旧报告，这部分逻辑与新增浏览器断言一致；原计划卡片由 manager 时间线重新挂载。
对主干的风险
P1 阻塞：不相关普通 Goal 会话会遮蔽有效团队报告。 真实 read_team 对未配置 coordinator identity 的会话返回 400；会话列表本身并不只包含团队会话。保持一份已验收源操作、当前采用关系和匹配的下游报告不变，只往同一 Goal 加一个普通聊天会话、让其 team operations 返回相同的 400：当前 head 的打包 team-plan 场景等待报告表格 30 秒后超时，界面进入“无法核验”。原始九个场景全通过，恰恰因为 fixture 对任意会话都能返回 team API。超过 8 个不相关会话同样会触发 incomplete。
最小修复是按回执 Todo ID 找权威的相关团队会话/公共安全 Goal 结果投影，并独立证明查询完整性；不要简单吞掉所有 400。请增加“有效采用结果 + 无团队配置的普通会话”和“有效结果 + 超过 8 个不相关会话”的打包负例，并重跑 npm run build --prefix apps/presentation/dashboard 与 npm run smoke:personal-workspace-packaged --prefix apps/presentation/dashboard。
我的整体评价
请求修改，当前 head d187367 暂不可合并。 正常路径、关闭/重载、刷新撤下旧报告与九个打包场景通过；但原任务要求把可核验结果可靠地返回 manager，混合会话反例推翻了这一点。无新增持久格式或权威；保留现有 typed API 即可，先修正结果发现/完整性边界再复审。真实多 Agent 验收仍在本 PR 宣称范围之外。
English verdict: REQUEST_CHANGES — an unrelated ordinary Goal session (or the eight-session cap) makes a valid adopted report disappear from the manager conversation; scope discovery and add mixed-session regressions before merge.
Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
d187367 to
f98ddf3
Compare
Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
Request changes conclusion (author-owned PR; GitHub blocks formal self-review)
Exact head: f98ddf3b8128cdff150f4b7069ec02e8c3576c57
动机
manager 确认 team.plan 后，原分配卡片应在关闭抽屉或重载后留在原对话；被当前采用的下游验收报告也应返回同一处。当前 head 能完成正常合成场景，但在同一个 Goal 同时有普通聊天会话时，会撤下一个本来已经通过版本核验的报告，因而尚未达到可靠返回结果的目标。
改动思路
应用 receipt 的 Todo ID 串起 manager 计划和 Goal Chat 操作；新 manager reader 再核对源操作、当前 adoption、下游操作与 artifact 版本。真正创建 Todo 仍只走 ChatActionService.apply。卡片持久化、刷新时先撤旧报告和 Goal 证据导航方向正确；问题在于 reader 将“列出的所有 Goal 会话都可读 team operations”当成全局完整性条件，而现有 session list 并不只包含团队会话。
具体改动
新增 manager 结果组件、时间线挂载、已应用提案的关闭/重载恢复、receipt Todo ID 提取、样式与打包资源；浏览器场景覆盖正常采用、丢失 apply 响应后的幂等恢复、移动端和刷新撤下旧结果。当前 head 相对先前 review head d1873678 是重基：关键 manager-team-result.tsx 的 Git blob 完全相同，原发现没有被修掉。
关键代码讲解
manager-team-result.tsx:10-21对 Goal channel 的全部 session 最多取前 8 个；总数超过 8 或任意 session 的 team operations 读取失败都会使全局incomplete为真。manager-team-result.tsx:23-62对匹配 receipt Todo 的已接受源操作、当前 adoption 与下游 artifact 做严谨版本匹配；这是该 UI 应保留的安全边界。manager-team-result.tsx:67-75在循环结束后让不相关 session 的失败覆盖已找到的有效报告，转为unavailable。personal-workspace-page.tsx:1103,1892让 applied team.plan 卡片可恢复且关闭 drawer 后不被删除；ChannelTimeline将只读结果放在原卡片下。
对主干的风险
P1 阻塞：不相关普通 Goal 会话会遮蔽有效采用结果。 后端 chat_loopx_mode.py:255-268 对未配置 coordinator identity 的会话明确拒绝 team readback。保持一个已验收源操作、当前 adoption、匹配的下游报告不变，只向同 Goal 增加一个普通会话并让其 team API 返回对应 400：当前 head 的打包浏览器页面在刷新后显示“团队结果或采用证据无法核验”，报告表格变为 0；临时场景只因原有断言要求唯一 503、现在另有注入的 400 才最终退出失败，报告消失的检查本身已通过。既有 9 个打包场景和构建全通过，因为 fixture 对任意 session 提供 team API。超过 8 个不相关 session 也会无条件触发 incomplete。
请按 receipt Todo ID 找权威的相关团队操作或完整的公共安全 Goal 结果投影，独立证明查询完整性；不要简单忽略所有 400，以免吞掉真正相关会话的错误。补入“有效结果 + 普通无团队配置会话”及“有效结果 + 超过 8 个不相关会话”两个打包回归，再跑 dashboard build 和 packaged browser smoke。当前 PR 每张卡片的 30 秒有界扫描也应在后续移到共享 Goal read model 或做可视区域订阅；这是具体的向前重构点，不要求为本阻塞另造一套状态。
我的整体评价
REQUEST_CHANGES，当前 exact head 暂不可合并。 正常路径、版本匹配、应用卡片持久化与刷新撤下旧报告都已验证，但混合会话反例推翻了最核心的返回结果承诺；既有 typed API 和写入权威可以保留，只需修正发现/完整性边界。真实多 Agent 验收仍在本 PR 声明范围之外。本轮按 Goal 配置未拉取或等待远端 CI。
English verdict: REQUEST_CHANGES - exact head f98ddf3b8128cdff150f4b7069ec02e8c3576c57; an unrelated ordinary Goal session or the eight-session cap hides a valid adopted report. Scope discovery to authoritative related operations and add mixed-session regressions before merge.
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
Request changes conclusion (author-owned PR; GitHub blocks formal self-review)
Exact head: 9b3a5ea6f6a7165db9cef27457d79a7e77de2557.
动机
经理在管家会话中应用 team.plan 后，需要在原会话看到持久的计划卡和下游已采用、已验收的团队报告，而不必每次跳去 Goal 手工重建证据链。原先关闭/重新打开抽屉后卡片会消失，也没有经理侧的结果回流。
改动思路
PR 让已应用卡片随会话恢复，把 apply receipt 的 Todo IDs 交给只读 ManagerTeamResult；它从 Goal 会话、团队 operation、adoption、source/consumer artifact 的 ID 与哈希逐层核验，只在当前且已验收时渲染报告，读取失败则撤回旧结果。写 Todo 的权威仍在 ChatActionService.apply。新 head 还先用 fetchLoopXMode 区分普通会话与有 coordinator 身份的团队会话，修复了上一次 review 指出的普通会话 400 导致误判。
具体改动
channel-timeline.tsx 接入已应用计划的结果区域；personal-workspace-model.ts、personal-workspace-page.tsx、team-plan-preview.ts 传递并恢复 Todo 身份与 Goal 跳转；manager-team-result.tsx 实现只读发现、采用链核验、刷新及四种 readback 状态；CSS 与打包资产同步展示；fixture 和 team-plan packaged browser 场景覆盖持久卡、结果呈现、失效证据，以及新加的 9 个普通会话。未发现新增 CLI/Lark 入口或额外 Todo 写入。
对主干的风险
P1，仍会错误撤回有效报告。 manager-team-result.tsx:18-30,87 对整个 Goal 的所有会话逐一取 mode，随后只要 coordinator 会话超过 8 个就设置 incomplete，并仅扫描前 8 个；最后这个全局标记无条件覆盖已经核验的 adopted 结果。一个与此 team.plan 完全无关的 coordinator 会话数量变化，因此足以把同一份有效报告变成“无法核验”，相关会话靠后时还根本不会被扫描。当前的新回归只添加 9 个普通会话，所以未覆盖这个分支。
我在打包浏览器场景中保持原 source/adoption/consumer 和 receipt Todo IDs 不变，仅暂时把 9 个无关普通会话改为带其他 coordinator 身份、其他 operation 的会话；点击刷新后报告表格从可见变为 0，页面显示“团队结果或采用证据无法核验”。移除这些无关身份后，同一报告恢复。临时验证改动已撤销，工作树干净。建议把发现与完整性绑定到 receipt Todo IDs 对应的 operation，或由现有权威提供完整、按相关性索引的 Goal 结果 read model；至少加入“有效采用 + 超过 8 个无关 coordinator 会话仍可见”及“真正相关证据不可读则撤回”的回归。
另一个相关成本：每张已应用卡每 30 秒对 Goal 的所有会话发一次 mode GET，再扫描至多 8 个团队会话。这是按总会话数和卡片数增长的读取，不只是一次性核验；修复发现边界时也应界定/复用这批读取。未见权限扩大或新的持久状态，但当前全局 cap/轮询成本不宜直接进主干。
验证：dashboard build 与 9 个既有 packaged browser 场景通过；额外的上述 targeted packaged browser 反例复现了 P1。对照了上次 review 的 head 与当前 head、后端 list_sessions/read_team 路径；未按本 Goal 的 wait_for_ci=false 配置轮询远端 CI，也未验证真实多 Agent 执行。
我的整体评价
REQUEST_CHANGES。卡片持久化、类型化采用链核验和普通会话过滤是有价值且方向正确的改进；但目前相关结果仍被无关 coordinator 会话的全局数量左右，无法证明“已验收报告可靠回到经理会话”。请修复上述 P1 并补反例回归后重新按新 head 评审。相邻的有界重构应让相关 Todo/operation 的读取与完整性判定由同一权威负责，避免 UI 重复建立全局会话索引。
English verdict: REQUEST_CHANGES - exact head 9b3a5ea6f6a7165db9cef27457d79a7e77de2557; nine unrelated coordinator sessions hide an unchanged verified adopted report due to the global eight-session cap. Build and nine baseline packaged scenarios pass; targeted packaged counterexample reproduces the blocker.
A Goal's sessions were ranked by a global cap: nine unrelated coordinator conversations were enough to mark discovery incomplete and withdraw an unchanged, already verified report, and every card rescanned every Goal conversation on each poll. Discovery now reads each conversation's own LoopX mode, which is that conversation's work index (the Todos it dispatched work for and the coordinator bindings it holds), and only a conversation naming one of the receipt's Todo identities can hold this plan's work. Unrelated ordinary or coordinator conversations neither enter the read budget nor withdraw a report, and they are never queried for delegation operations. A conversation whose mode cannot be classified, a related conversation above the lane bound, and an unreadable related inventory still withhold the result, so an unattributable readback never claims a verified conclusion. The Goal work index is read once per window and shared by every applied card, and an explicit refresh re-reads it, so per-card cost no longer scales with every conversation in the Goal. Acceptance adds nine unrelated coordinator conversations alongside the nine ordinary ones and asserts the accepted report stays visible, plus an unreadable inventory for the related conversation that must withdraw it. Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
…unch-journey Generated Chat assets conflicted as delete/modify: main now builds and qualifies the bundle outside Git, so this branch's regenerated assets are resolved by keeping every loopx/web/chat path deleted and rebuilding from the merged source. No other conflict remained. Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
Reviewed exact head e8fe7551e1c479e8e2934be678731aae337770f6 against base 312934cf34e1e46c8ab3eab99d69a58b29aa773c.
动机
经理在管家会话确认 team.plan 后，需要在原会话持续看到计划卡与下游已采用、已验收的报告。上一轮评审在 9b3a5ea6f 上指出 P1：结果发现被一个全局协调者会话上限支配，只要同一 Goal 里出现超过 8 个与之无关的协调者会话（更早一轮是普通会话），一份内容完全未变、仍处于当前采用状态的有效报告就会被判为「无法核验」而撤下；同时每张已应用卡片每 30 秒都会扫一遍该 Goal 的全部会话。本 head 修复这两点。
改动思路
发现的权威不再是「Goal 里有多少协调者会话」，而是计划自己的 Todo 身份：apply receipt 的 resource_ids.lane_todo_ids 是计划与团队工作之间的唯一连接键。每个会话自己的 LoopX mode 就是它会话内的工作索引——它派发过哪些 Todo 的工作（deliveries）以及它被配置的协调者绑定（members）。只有名称命中 receipt Todo 的会话才可能与本计划相关，才进入读取预算。
因此：无关会话（普通会话或其它协调者会话）既不参与预算，也不能撤下报告，更不会被查询 delegation operations；完整性只由「相关」证据决定——相关会话的 inventory/read 不可读、某个会话的 mode 无法分类、或相关会话数超过计划可能的 lane 上界时，仍然撤回，绝不在无法归属的读回上声称「已验收」。写 Todo 的权威仍只在 ChatActionService.apply，本次没有新增投影、存储或写入路径。
具体改动
manager-team-result.tsx：新增按 Goal 的工作索引（会话 → 该会话 mode 里出现的 Todo 身份），以 30 秒窗口读取一次并在所有已应用卡片间共享（并有并发去重）；显式点击「刷新结果」强制重读。readAdoptedResult只用「名称命中 receipt Todo」的会话做核验，删除全局teamSessions.length > 8与全局 incomplete 覆盖，改为：4xx（服务端明确拒绝该会话的团队读回，例如未配置协调者身份）视为无关，其它不可读视为不可分类并撤回；相关会话超过 8 个时撤回。既有「新读取开始时立即撤下旧报告」保持不变。examples/personal-workspace-browser/fixture.mjs：会话 mode 现在体现真实服务端的语义——某会话的deliveries就是它为哪些 Todo 派发过工作（fixturePlanTodoId派生），并新增fixtureTeamInventoryError表示相关会话的 inventory 读失败。examples/personal-workspace-browser/team-plan.mjs：在原 9 个无关普通会话之外，再补 9 个无关协调者会话（各自持有别的 Todo 与别的 operation），断言有效报告仍可见、且这些会话从未被查询operations；新增「相关会话 inventory 不可读 → 撤回报告」；末尾的失败响应断言改为只允许注入的两次 503（apply 与相关会话operations）。- 合并最新
main：冲突全部是生成产物（loopx/web/chat/**的 delete/modify 与 rename/delete）。按 main 的前端交付策略，解决方式是保持这些路径在 Git 中删除、不再提交生成物，随后用合并后的源码重建并通过verify --source；本次 diff 已不含任何loopx/web/chat路径。
对主干的风险
上一轮的 P1 现在有可复现的守门：把修复前后的组件与同一份新场景对照跑，修复前 team-plan 场景在报告表格处 30 秒超时失败（正是 9 个无关协调者会话把报告撤下的反例），修复后通过。另有一个更贴近真实服务端的负例——相关会话 inventory 返回 503——同样撤回报告，说明完整性没有被放宽成「忽略所有失败」。
验证矩阵（本 head）：打包 dashboard 生产构建 + chat_bundle.py verify --source 通过；10 个打包 Personal Workspace 场景全部通过（含上述两类混合会话、相关证据不可读、移动端可读与 Goal 证据跳转）；team plan proposal 单元 smoke 与 PWA bundle smoke 通过。examples/repository-hygiene-smoke.py 在改动范围外失败，且在未修改的 origin/main 上同样失败（tests/control_plane/test_public_safety_text_budget.py:19 的合成凭据注释），与本 PR 无关。远端 CI 按本 Goal 的 wait_for_ci=false 未等待。change-quality receipt：cqr_ff9bb74565ee0f9d1bd9（decision=pass）。
残留边界（已记入 receipt 的 advisory 风险）：相关性依据的是会话 mode 的 deliveries，服务端仅保留最近 20 条，因此一个极其长寿的协调者会话若已把本计划 Todo 的那条记录挤出窗口，卡片会显示「尚无可核验的已采用结果」而不是报告——这是偏保守的漏报而非误撤，Goal 页面仍是权威；共享工作索引仍为每个 Goal 会话每个 30 秒窗口一次 mode 读取（与卡片数量无关，且无关会话不再触发 operations 读取）。原生多 Agent 执行、Lark/CLI 等待一致性仍按 PR 声明的范围不在本次验收内。
我的整体评价
APPROVE：P1 的根因（全局上限 + 无关会话的全局 incomplete）已被删除，而不是被调大；发现与完整性绑定到了 receipt 的 Todo 身份，相关/无关/不可分类三态有明确语义，并新增了两个会在旧实现上失败的打包回归（其中「9 个无关协调者会话」正是上一轮的复现路径）。卡片持久化、采用链版本核验与写入权威未变，改动仍是单主题、可回滚的前端范围。
English verdict: APPROVE - exact head e8fe7551e1c479e8e2934be678731aae337770f6 binds manager result discovery to the apply receipt's own Todo identities and treats each conversation's LoopX mode as its work index, so nine unrelated ordinary or coordinator conversations can no longer withdraw an unchanged verified report, unrelated conversations are never queried for delegation operations, one shared per-Goal work-index read replaces per-card scans, and genuinely unreadable related evidence still withdraws; the packaged ten-scenario run passes and the new counterexample fails on the pre-repair component. Receipt cqr_ff9bb74565ee0f9d1bd9.
|
Self-repair and merged decision record (admin-bypass merge, maintainer-authorized).
Repair content:
Validation at the merged head:
|
1 participant
Problem and result
A manager-confirmed team assignment disappeared from the original conversation after closing its drawer or reloading. Even when a Goal Chat coordinator later adopted an accepted report, an unrelated ordinary Goal conversation could make that report appear unverifiable; more than eight ordinary sessions could hide it without any read failure.
The manager now keeps the applied assignment in the original conversation and links it to team work through the apply receipt's canonical Todo IDs. It discovers only sessions with a configured coordinator identity, checks every candidate inventory page, and displays a readable downstream report only when source acceptance, current adoption, consumer acceptance, and exact artifact versions match. An unreadable session or inventory page withholds the report. Refresh immediately withdraws stale content; the user can open the Goal conversation to inspect evidence and intervene.
Validation
9b3a5ea6f: dashboard production build and packaged bundle smoke passed.cqr_12dfef5358aa54c75ba6is valid for 14 changed files. Goal-scoped premerge passed three direct checks and five selected checks, with zero failures or manual holds. All commits carry DCO sign-off.This changes the packaged dashboard's manager and Goal Chat journey. Lark and CLI retain their existing typed team-work APIs. The result readback covers Goal Chat delegation sessions; managed executions without that inventory still need a shared public-safe Goal result projection. Browser acceptance uses synthetic operations, so live mixed-model launch, independent review, adoption, scoped stop, and first-use qualification remain separate product acceptance work. Product code remains for maintainer review and merge.